Skill Gaming Policy Thread

[Yingzi Xue]

---

Phil Deakins wrote:

---

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.

---

Phil, the "your" was hypothetical, I wasn't referring to an actual script that exists.  Innula and I were writing responses at the same time (the script posts), hers just posted a few minutes before mine because I'm an edit freak.  Then a conversation ensued.

[Phil Deakins]

---

Sorina Garrigus wrote:

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.

---

Sure it was

I've followed this thread from the start and I've read every post in it, and I don't recall the 'freeplay' games being discussed. That doesn't mean they weren't discussed but, if they were, I don't think there was any significant arguments going on, at least not to extent that you would consider the arguers "trolls and pointless arguers", anyway. I thought I was your favourite troll in this thread and I certainly haven't addressed 'freeplay' games as described by Derek and LL. So, of course, I'm wondering if you are imagining things.

[Phil Deakins]

I thought you meant my script, since you included my name. I thought you'd misunderstood something, as Innula did.

[Yingzi Xue]

---

Phil Deakins wrote:

I thought you meant my script, since you included my name. I thought you'd misunderstood something, as Innula did.

---

No, I was just mentioning you since the conversation started with your post, was being inclusive.

[Sorina Garrigus]

---

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!

---

Quite of few if not all of the Ravkom, PI games, and Cookies all have a menu start option for freeplay but they also worked with the pay L$1 approach as well. Of all of those Cookies is the only one on the freeplay version that doesn't have a pay L$1 option.

 I believe game creators were trying to save on extra scripting and memory usage. Games check for amount paid in to see if its correct so refunding when its not is usually done so a menu driven game start is extra. This was especially the case with older games back when 30ish scripts for a game was common.

Even without LL clairifying the L$1 pay in and refund was ok for freeplay, it was clearly within the spirit of what the new policy is about.

Additionally it should be noted there is no point for a game that is set strictly set to freeplay to have a pay in of L$1 to triger the game to start. The only reason games do this is if they can be set to pay and win. The reason this is in the FAQ is because of games set to freeplay are not within the scope of the skill game policy including games that could potentially be used otherwise such as older games. The policy isn't like what some have said in this thread where essentially all game since the begining of SL are restricted to skill game regions even if set to be within this new skill game policy.

But to avoid confusion it is probably best to request a game maker assuming they are currently active for an update with fixed freeplay games if they are going to be used as such. appropriately. I for one have quite a few games that it won't be likely or possible to be updated.

 

[Phil Deakins]

---

Sorina Garrigus wrote:

Additionally it should be noted there is no point for a game that is set strictly set to freeplay to have a pay in of L$1 to triger the game to start. The only reason games do this is if they can be set to pay and win. The reason this is in the FAQ is because of games set to freeplay are not within the scope of the skill game policy including games that could potentially be used otherwise such as older games. The policy isn't like what some have said in this thread where essentially all game since the begining of SL are restricted to skill game regions even if set to be within this new skill game policy. 

---

Let's be absolutely clear about this. If a 'freeplay game' CAN be set by the operator to pay-to-play and win, with no immediate refund, then it does come under the new policy. As long as a pay-to-play and win option is contained in the game, it falls under the new policy, whether the option is used or not.

I'm not entirely sure that you wrote anything different in the paragraph that I've quoted, but I wanted to make it clear.

[Innula Zenovka]

---

Phil Deakins wrote:

---

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.

---

I've been thinking about why anyone would want to set a gaming machine to charge L$1 and then refund it, and the only answer I can think of it is that it's a way of recording who's played the game that doesn't use up memory storing them locally or involve sending the uuids to an external database.  

Instead, you simply look at your transaction record.

Quite why you'd want the identities of individual players rather than data about how many people were playing is another matter, but I bet that was the original thinking behind it.   I can't come up with any other half-way sensible explanation, at least not for a game that's designed to be free to play as opposed to one that can be set by that owner as either free-to play or pay-to-play.  

I've not really looked into it but I think that the new experience tools, when they're rolled out, will enable creators to use Key-Value pairs to store this kind of data on LL's servers rather than have to resort to kludges like this (though presumably LL will need to set some kind of limit on the amount of data they're prepared to store for free).

[Phil Deakins]

It makes me wonder if there are any games at all that are solely pay-and-refund-immediately that can't be set by the owner (operator) to pay-and-win. I suppose the must be some for LL to add that bit into the FAQ, but maybe not. Maybe they just added it in case there are any.

[Yingzi Xue]

Back in 2008, I wanted to store sales data for my stores, so I created a simple in-world server object.  I would periodically move the data off to a spreadsheet on my PC with copy/paste.  I did that for years with great success, even though the storage space was quite small (16k).  In the event memory got low, I would drop old data.  I used email and chat history as a backup, so I had two redundancies.  Nowadays I use HTTP and an external server.

How the pay-in-instant-refund idea got traction with game creators is a mystery, but even in a pre-MONO and HTTP world, there were more robust options.  If it were me, I would've complained to the creator for clogging my transaction history with pay spam until they removed it or made it optional.

I'm sure free-to-play games still exist, somewhere in obscure corners of the grid, where people still cling to ideas like community and having fun.  

Actually, KR Engineering games now fit the bill since they don't accept pay in anymore.

[Sorina Garrigus]

---

Phil Deakins wrote:

---

Sorina Garrigus wrote:

Additionally it should be noted there is no point for a game that is set strictly set to freeplay to have a pay in of L$1 to triger the game to start. The only reason games do this is if they can be set to pay and win. The reason this is in the FAQ is because of games set to freeplay are not within the scope of the skill game policy including games that could potentially be used otherwise such as older games. The policy isn't like what some have said in this thread where essentially all game since the begining of SL are restricted to skill game regions even if set to be within this new skill game policy. 

---

Let's be absolutely clear about this. If a 'freeplay game' CAN be set by the operator to pay-to-play and win, with no immediate refund, then it

does

come under the new policy. As long as a pay-to-play and win option is contained in the game, it falls under the new policy, whether the option is used or not.

I'm not entirely sure that you wrote anything different in the paragraph that I've quoted, but I wanted to make it clear.

---

Then the pay to start for freeplay was 100% pointless to even mention. There is nor ever has been a game made that is strictly freeplay that pays out money that had a pay to start the game feature. This only happens in games where paying to play is an option. For you to say otherwise demonstrates you have no clue about how games operate in SL. Furniture sure but clearly nothing about games.

LL has made it clear in multiple places games that are freeplay are not in the scope of the policy. That FAQ on pay to start makes it even more clear until they clearly state otherwise.

[Sorina Garrigus]

---

Yingzi Xue wrote:

Back in 2008, I wanted to store sales data for my stores, so I created a simple in-world server object.  I would periodically move the data off to a spreadsheet on my PC with copy/paste.  I did that for years with great success, even though the storage space was quite small (16k).  In the event memory got low, I would drop old data.  I used email and chat history as a backup, so I had two redundancies.  Nowadays I use HTTP and an external server.

How the pay-in-instant-refund idea got traction with game creators is a mystery, but even in a pre-MONO and HTTP world, there were more robust options.  If it were me, I would've complained to the creator for clogging my transaction history with pay spam until they removed it or made it optional.

I'm sure free-to-play games still exist, somewhere in obscure corners of the grid, where people still cling to ideas like community and having fun.

 

Actually, KR Engineering games now fit the bill since they don't accept pay in anymore.

---

Yes free to play games exist in SL and they are hardly obscure. They are mostly used for casual attractions or more so for personal use with friends. Hell some games never had money in or out even as a consideration. I have tons of games board and card games myself. I have a SL version of settlers of Catan called Settlers of Second Life. Its rather old, highly primmy and a whole lot of scripts though so I don't really keep it out. some of the best examples are hard to find though. I been going through my inventory and pulling out old games in a adboard support approach. In the arcade department some of the most impressive creatons have been Super Rally and Komikaze. There is a line of working pinball games, Brock Games has a  huge line of card and board games, There are a variety of chess and other ancient games out there, There is a game called Warlords which plays in a similar fashion to the civilization type games etc so on. Then there are a few shooting type games out there like a zombie/monster shooting game more sim based though. There are a couple CCG type games in SL etc so on.

There are a LOT of games in SL. Not just slingos and a couple recently updated games formerly with pay in options.

 

"How the pay-in-instant-refund idea got traction with game creators is a mystery"

It is hardly a mystery for people with any experience with games but those that don't probably wonder why but it makes sense when applying a little common sense. The pay and win games already have a pay to start feature in place. They have to check amounts and as part of those routines they tend to refund incorrect amounts. They don't have to I suppose. the only incorrect amounts are from those using "hacked" viewers trying to steal. The alternative would be to create an entirely separate click to start or menu driven to start taking up extra script, memory and possibly using up extra script time. Not a big deal with one or two games but depending on the game it could be close on script memory but more importantly they tend to think and consider game rooms with more than a handful of games present and all those scripts add up adding to lag.  Games that never had a pay in feature of any kind have never had a pay to start feature. Karstens games use to be configurable to pay OR click to start. Same thing with Riffkin's games. But the primary purpose and design wasn't for commercial use and those types of games typically don't have a whole bunch of duplicates in the same sim so script time etc isn't as much of a concern.

 

[Yingzi Xue]

It's possible to create a session system without menus by keeping track of the player key and the status of the game.  I just wrote an example script which uses around 575 bytes of 16k script memory.  At the very minimum, if designed properly, session code is small taters.  You could add a timer to expire a session if the player leaves mid-game, which is a few extra lines of code.  A timer would be minimal impact, being set for something like 5 minutes.  Approximately 685 bytes used.  That's with all the code necessary to maintain a session, compiled in LSL2, not MONO.  Yes, the code needed for menus can memory intensive, but menus are not required at all.

[Sorina Garrigus]

---

Yingzi Xue wrote:

It's possible to create a session system without menus by keeping track of the player key and the status of the game.  I just wrote an example script (not posted here) which uses around 575 bytes of 16k script memory.  At the very minimum, if designed properly, session code is small taters.  You could add a timer to expire a session if the player leaves mid-game, which is a few extra lines of code.  A timer would be minimal impact, being set for something like 5 minutes.  Approximately 685 bytes used.  That's with all the code necessary to maintain a session, compiled in LSL2, not MONO.  Yes, menus are memory intensive, but not required at all.

---

It is possible obviously and some do but on freeplay games with pay and win options built in it extra scripting. And the impact on the sim can easily be multiplied by a couple hundred in even a moderately sized game room or arcade.

Some games would require menus but most wouldn't. I have one called Galaxy War which is one of my favorites to play that has multiple config options. Players set if its co-op, or competitive, or how many computer opponents there are, the AI difficulty level etc.

There are just way too many game mechanics and various other options to say menus are not required at all.

[Phil Deakins]

I don't quite know what you're getting at. In the first place, I didn't bring freeplay games up. I merely joined in the discussion about them. Secondly, We knew right at the start that games that are free to play and pay out, AND.that don't include an owner-option to set them as pay-to-play, don't come under the new rules. The new addition is that LL has now made it clear that the policy does not encompass games that require a nominal payment to trigger them, and the nominal payment is refunded immediately, provided that those games do not include an owner-option to set them as pay-to-play (without instand refund) and win money

So we come to this bit:-

---

Sorina Garrigus wrote:

There is nor ever has been a game made that is strictly freeplay that pays out money that had a pay to start the game feature. This only happens in games where paying to play is an option

.

For you to say otherwise demonstrates you have no clue about how games operate in SL. Furniture sure but clearly nothing about games.

---

I don't believe I've said otherwise, and I've never claimed to know much about games, other than the 4 that I have in a Games Room in my store.

This bit puzzles me though. What you seem to be saying is that games that pay out according to the result, and that do what LL described as "freeplay games", and also have an owner settable option for pay-to-play - i.e. pay-in but no refund, and pay-out - are also not encompassed by the policy. I may be mistaken but that's what is looks you are saying. If you are, then you are dead wrong. Or you may be saying that no games exist, or ever did exist, that are described by LL's "freeplay games" description, in which case, there was no need for the addition to the FAQ. Perhaps you'd like to make it clear exactly what you are saying.

ETA: DerekShane was the one who posted the new addition to the FAQ, and he seems to think that freeplay games that ONLY refund immediately do exist. He also agrees that any freeplay games that include an owner-settable 'pay to play and win' option come under the Skill Gaming Policy. You're not writing very clearly, so I don't actually know if you also agree or not.

[Phil Deakins]

---

Sorina Garrigus wrote:

It is possible obviously and some do but on freeplay games with pay and win options built in it extra scripting. And the impact on the sim can easily be multiplied by a couple hundred in even a moderately sized game room or arcade.

---

I'm sorry, but that's nonsense. You may know a lot about the owner side of games but you don't know much about scripting. Drop-down menus add very little to a script and have almost no impact on a sim. The only impact is one addition 'listen', which is negligable, and, if it's been written well, it only last for a for a period that can be counted in seconds. I may not know much about games, but I know an awful lot about scripting

There is no scripting, or sim impact, reason for a game to have pay-to-play-and-instant-refund. In a previous post you seemed to say that no "freeplay games" exist that can be described by LL's description. You seemed to say that freeplay games do exist but they also include pay to play and win with no instant refund. Such games are subject to the Skill Gaming Policy.

[Sorina Garrigus]

Learn to read. you will be a much more succesful troll in the future if you do.

Edited to expose troll comments.

Troll Wrote: DerekShane was the one who posted the new addition to the FAQ, and he seems to think that freeplay games that ONLY refund immediately do exist

DerekShane  wrote "I can't think of any game except Zyngo without that L$1 requirement."

NOTE: Zyngo has no freeplay only version.

Troll Wrote:   you don't know much about scripting... Drop-down menus add very little to a script and have almost no impact on a sim"

NOTE: Never claimed scripting knowledge and I never commented on pop up menus being efficient or not. Yingzi did.

Yingzi Xue  wrote "Yes, the code needed for menus can memory intensive, but menus are not required at all"

[Innula Zenovka]

---

Sorina Garrigus wrote:

---

Yingzi Xue wrote:

"How the pay-in-instant-refund idea got traction with game creators is a mystery"

---

It is hardly a mystery for people with any experience with games but those that don't probably wonder why but it makes sense when applying a little common sense. The pay and win games already have a pay to start feature in place. They have to check amounts and as part of those routines they tend to refund incorrect amounts. They don't have to I suppose. the only incorrect amounts are from those using "hacked" viewers trying to steal. The alternative would be to create an entirely separate click to start or menu driven to start taking up extra script, memory and possibly using up extra script time. Not a big deal with one or two games but depending on the game it could be close on script memory but more importantly they tend to think and consider game rooms with more than a handful of games present and all those scripts add up adding to lag.  Games that never had a pay in feature of any kind have never had a pay to start feature. Karstens games use to be configurable to pay OR click to start. Same thing with Riffkin's games. But the primary purpose and design wasn't for commercial use and those types of games typically don't have a whole bunch of duplicates in the same sim so script time etc isn't as much of a concern.

 

---

 I'm a bit surprised by this explanation.   Sure, if I wanted to make a game that was configurable to be either pay to play or free to play, then I can see that charging and immediately refunding the L$1 would make sense.

However, if I were writing a free to play game, or even converting a game to be strictly free-to-play, I really wouldn't want completely unnecessary run time permissions or money events cluttering the script up.   Not when the alternative is to do everything in a touch event.

More likely, to my mind, is that if you've made a pay to play game and want to make a free-to-play alternative, the easiest (though certainly not the most efficient) way to convert it is to re-write part of the money event, even though that means leaving a lot of stuff in that's not really needed.

[Yingzi Xue]

---

Sorina Garrigus wrote:

It is possible obviously and some do but on freeplay games with pay and win options built in it extra scripting. And the impact on the sim can easily be multiplied by a couple hundred in even a moderately sized game room or arcade.

Some games would require menus but most wouldn't. I have one called Galaxy War which is one of my favorites to play that has multiple config options. Players set if its co-op, or competitive, or how many computer opponents there are, the AI difficulty level etc.

There are just way too many game mechanics and various other options to say menus are not required at all.

---

Menus aren't required at all if you use notecard configuration or external configuration.  There are ways to get around menus and save on memory.  I have a product that uses menus, texture cycling and timers.  Hundreds rezzed in the same region and still good performance.  It's all in the design.  Many factors cause lag.

[Phil Deakins]

---

Sorina Garrigus wrote:

Learn to read. you will be a much more succesful troll in the future if you do.

When you have a fraction of the success that I've had in SL, come back and talk again

Edited to expose troll comments.

Troll Wrote:

DerekShane was the one who posted the new addition to the FAQ, and he seems to think that freeplay games that ONLY refund immediately do exist

You're mistaken. It was me who wrote that, not Troll lol

DerekShane

  wrote "I can't think of any game except Zyngo without that L$1 requirement."

NOTE: Zyngo has no freeplay only version.

You're mistaken. You picked the wrong bit of Derek's post LOL

Troll Wrote:   you don't know much about scripting... Drop-down menus add very little to a script and have almost no impact on a sim"

You're mistaken. It was me who wrote that, not Troll lol

NOTE: Never claimed scripting knowledge and I never commented on pop up menus being efficient or not. Yingzi did.

Yingzi Xue

  wrote "Yes, the code needed for menus can memory intensive, but menus are not required at all"

Perhaps she did, but you also posted it, and you know next to nothing about it

---

Suggestion: Listen to Innula. Then you might learn something.

Another suggestion: Listen to everyone else, and then you won't be the odd one out

Yet another suggestion: Write what you want to say so that it's clear. Then you won't be misunderstood. As it is, it's simply unclear what you've been trying to say in some of your latest posts.

 

[Yingzi Xue]

---

Innula Zenovka wrote:

I'm a bit surprised by this explanation.   Sure, if I wanted to make a game that was configurable to be either pay to play or free to play, then I can see that charging and immediately refunding the L$1 would make sense.

However, if I were writing a free to play game, or even converting a game to be strictly free-to-play, I really wouldn't want completely unnecessary run time permissions or money events cluttering the script up.   Not when the alternative is to do everything in a touch event.

More likely, to my mind, is that if you've made a pay to play game and want to make a free-to-play alternative, the easiest (though certainly not the most efficient) way to convert it is to re-write part of the money event, even though that means leaving a lot of stuff in that's not really needed.

---

Exactly. I agree with everything you said.  Speaking to all here:

If you're writing an all-in-one solution (free-to-play and pay-to-play), the tendency would be to just make it configurable with both options, but the efficiency-minded creator would probably make two versions, ripping the "dead" code out of the free-to-play version to save on script memory.  I remember at one time there was talk of LL rationing out script memory (EDIT: Per discussions in 2009 and a 2010 LL blog post that has since been deleted; see more here).  If you look at Script Info under About Land, General tab, some (if not all) of the code seems to be in place to limit script memory on a per parcel basis.  Even though it may never be implemented, it makes sense to be as efficient as possible (my main point from the last several posts).  I made that commitment a long time ago.

[Sorina Garrigus]

I have no interest in talking to you about your trolling success. and if your takling about other kinds of success you don't even have a marketplace to sell your lame furniture in. Lastly you have no clue about my degree of success or not.

 

You keep firing off boomarang bullets and they keep flying back and smacking yourself in the head and you respond with LOL and various emotes declaring you won. anyone that does that just looks like a bafoon.

 

[Sorina Garrigus]

---

Yingzi Xue wrote:

---

Sorina Garrigus wrote:

It is possible obviously and some do but on freeplay games with pay and win options built in it extra scripting. And the impact on the sim can easily be multiplied by a couple hundred in even a moderately sized game room or arcade.

Some games would require menus but most wouldn't. I have one called Galaxy War which is one of my favorites to play that has multiple config options. Players set if its co-op, or competitive, or how many computer opponents there are, the AI difficulty level etc.

There are just way too many game mechanics and various other options to say menus are not required at all.

---

Menus aren't required at all if you use notecard configuration or external configuration.  There are ways to get around menus and save on memory.  I have a product that uses menus, texture cycling and timers.  Hundreds rezzed in the same region and still good performance.  It's all in the design.  Many factors cause lag.

---

Check out Galaxy War at my place. It has a lot of player options and Its a big 10 meter board with planets all above it. It is east of the landing zone. Also Solitaire by Paso Clip is another good example as it is a multi game ie can play a wide variety of solitaire style card games on it.  I agree in many if  not most cases menus always required are there are plenty of exceptions. Sure you can make something all hud based or have a prim control pannel pop up but that would add prims and scripts. note card configs are mostly only useful when setting a game in a fixed way. Solitaire actually uses both note cards and popup windows.

 

[Phil Deakins]

---

Sorina Garrigus wrote:

I have no interest in talking to you about your trolling success. and if your takling about other kinds of success you don't even have a marketplace to sell your lame furniture in. Lastly you have no clue about my degree of success or not.

You don't want to talk to me again? Twice before you've said that you are finished talking with me. You just can't keep your word, can you lol.

But I didn't mean my trolling success. I have absolutely no success in that - because I'm not a troll. I meant my financial success in SL. You're right that I don't have a presence in the marketplace. I never need it - ever. My "lame furniture", as you put it, made me thousands of US$ each and every month.That's the success I was talking about. You're right though. I have no idea about the degree of your success. I know about mine, and I'm quite confident that it outshines almost everyone who has had a business in LL, including you 

You keep firing off boomarang bullets and they keep flying back and smacking yourself in the head and you respond with LOL and various emotes declaring you won. anyone that does that just looks like a bafoon.

It's alright if I look like a buffoon to you (buffoon with a 'u' incidentally, not an 'a'

 ). I'm happy to see that you continue to stand alone and everyone else posts against your reasonings and arguments. I'm not sure who's the actual buffoon here, but I'm happy either way

---

I'm also happy to give you a spelling lesson. I hope you appreciate it

[BisKreet]

I am looking for clarification on the below part of Skill Gaming Policy.

REF: Linden Lab Official: Second Life Skill Gaming Policy

***Games in which Second Life residents do not pay to play are not within the scope of this Skill Gaming Policy

My question go to owning and using items that have the capability of being a skilled game, but not used in that way

i.e. If you have a gaming table such as dice game but do not use the pay to play function built in to it.  Would this be conceded a validation?

This really should be clarified in the Skill Gaming Policy.

 

Bis

[BisKreet]

Skill Gaming Policy / Intent of item use

 

I am looking for som oclarification on Skill Gaming Policy as intent of a scripted item has not been fully defined.

I.e.  If  a developer offers a traditional Sploder and changes its intent by renaming it club Tip Jar.

As you can see the intent of  use has completely changed as there is nothing wrong with the owner of the item to give something back in the process.

 

Bis