Jump to content

Script That Allows Purchase From the Demo?

You are about to reply to a thread that has been inactive for 257 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

15 hours ago, FairreLilette said:

But, what's confusing is the above is not true.  Vendors, tipjars, all kinds of things take our lindens without asking first.  Therefore, it does seem to have a disconnect somewhere and/or a gap is filled somehow.  Perhaps that main gap is CasperVend and it's system with a transaction number, etc....but it never asks if it can take money from me.  

Oh well, it seems LL has written themselves into a forever box they cannot get out of.  The only thing that saved LL from it's forever box is CasperVend then.  

No. No. No.

A vendor in a store doesn't TAKE customers' lindens. Customers perform an action which GIVES a designated amount of lindens through the pay box.

Debit permissions are a different beast.

You've gotten yourself into a forever box of your own making by not understanding this distinction.

  • Thanks 1
Link to post
Share on other sites
  • Replies 79
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

You can do this securely, however it comes at a cost. Basic idea of what you'd need to do: Have a button to "buy full version" on the hud Pop up a dialog explaining the debit permiss

You could certainly write an easy script that opens a link to the page in the creator's MP store where the full item is.  That would be a nice, secure way to make a purchase without needing to got to

Let's start with the scenario that Franco has a demo of Stalin's product; Franco wants Stalin's product and Stalin wants Franco's money. Unfortunately they're both mutually untrustworthy (but in case

4 hours ago, Rolig Loon said:

Nope.  I already explained that to Fairre yesterday. When you wear or sit on an object, PERMISSION_TRIGGER_ANIMATION is granted automatically and silently. The script still has to ask for permission, but you never see the request yourself. 


As you can see from this table, the same is true for PERMISSION_TAKE_CONTROLS, PERMISSION_TRACK_CAMERA, PERMISSION_CONTROL_CAMERA, and  (under some conditions) PERMISSION_ATTACH and PERMISSION_OVERRIDE_ANIMATIONS.  All of the other possible permissions will pop up a little box that asks you to grant permission explicitly.  Those silent, automatic permissions are low-risk ones that will not end up affecting your L$ balance, disrupting objects, or changing access to land. If they didn't work that way, many common things like AOs would be impossible or at least very annoying to use.  PERMISSION_DEBIT, on the other hand, is made deliberately obvious and annoying to keep it from being abused. 

Whether permissions are automatic or not, a script must still request them in order to affect the flow of operations from one set of commands in the script to another. Under some circumstances, a clumsy or inexperienced scripter can get away with not asking for an automatically-granted permission, but risks the chance that the script will fail. Under those circumstances, the script will still shout an error message.

Oh, okay...I didn't quite understand the difference...that's why this is a very odd category because it wasn't a thread about scripts but if a script could be made to work so we could purchase through a demo say in our own SL home...but it's not possible as you read through Rolig's, Wulfie's, Chaser's, Qie's and Paul's posts because we'd all be owner of any kind of hypothetical purchase HUD.  Though my script which I bought is a little confusing as it says in nearby chat window - requesting permission and then permission granted...it actually doesn't need those permission scripts nor any menus to work is what I was saying and it's really neither here nor there as this kind of purchase HUD could not work without allowing it permission and then it could continually run as Rolig and others are explaining in this thread *if* it were made by a clumsy scripter - meaning it would just keep taking lindens out of our account if it were made by a clumsy scripter.  My contest board does not continually run because it wasn't made by a clumsy scripter...it shuts off at end of the contest and I have to give it Permission_Debit for every single contest.  Contest boards are a tricky and rare kind of object to work.

But, also, I wasn't sure if Wulfie was talking about those kinds of objects where you sit and an object attachs to you and then detaches like in some SL restaurants for example but all that is a timed script removing the drink from your hand...but it's weird how some objects seem to come out of nowhere and attach like a drink for instance...just weird.   I wasn't sure if Wulfie was talking about those kinds of auto attach and detach items that seem to come out of nowhere.  I don't have any of those kinds of animated objects.   But, again, it's not a big issue unless someone wants to learn how to make any of these kinds of items, then they need a new 'how to' kind of thread.  

But, here's the final verdict from Page 4 of this thread on any kind of hypothetical PURCHASE HUD or VENDOR.  It won't work because we all would be owner.  Below is copy/paste from Page 4 of Rolig's and my posts.  It cannot be done because since it's an object owned by us we'd have to give it Permission_Debit.  Read whole thread.  

  17 hours ago, Rolig Loon said:

5. However, If you owned a scripted object (HUD or standalone box) that is supposed to send someone else money for you, you would own it and you would have to give the HUD PERMISSION_DEBIT to transfer money.  That's because the HUD is not you.  It's a separate object that needs your permission to transfer money on your behalf.     

Okay Rolig...it's this one.  It's the ownership of the object - the hypothetical PURCHASE HUD or PURCHASE VENDOR would be owned by each of us.

It's like my contest board.  I own my contest board.  I have to authorize it (via scripts and config cards) to take money out of my account and transfer the monies to the winner(s) and give it what is called "Permission_Debit" by accepting.  So, yes, it's all about the ownership thing of the object itself.   I see now.  Oh well...it was worth a try.  I was also wondering why it was never tried before...I can see the reason why now.  There isn't a work-around because of ownership.  

Edited 16 hours ago by FairreLilette

Edited by FairreLilette
Link to post
Share on other sites
3 hours ago, Bitsy Buccaneer said:

A vendor in a store doesn't TAKE customers' lindens. Customers perform an action which GIVES a designated amount of lindens through the pay box.

Debit permissions are a different beast.

You've gotten yourself into a forever box of your own making by not understanding this distinction.

I never said it takes our lindens as in "myteriously" without any action.  Read through the whole thread before you comment as it was already resolved in posts before yours.  

All monetary systems have actions to take our money...they are just different processes.  

As I wrote above and in another post before yours if you have had read all the thread before posting...I explained a few things and that I did understand it...  But, let me explain how it works since you just said it's a beast which gives no explanation at all.

A hypothetical purchase hud or vendor will not work because we own it.  Since we own it, we have to give it a command to take/accept whatever word you want to use to take our lindens and transfer those lindens to another person because we are owner of the object.

A contest board is like a vendor, and a hypothetical purchase hud or vendor would basically work the same way as a contest board.  A contest board because of our accepting Permission_Debit transfers the lindens out of our account to the winners - those of us who own contest boards, which is a fairly rare item in SL, I'd say.   A hypothetical purchase hud or vendor would work the same way as a contest board but since we own it...we'd have to accept the Permission_Debit to transfer the lindens to the seller/creator.  However, due to clumsy scripters, it could be abused; i.e. not shut off and just keep taking lindens.  

As far as the Lindens in a forever box because of how their Permission_Debit works...they may have done the only thing they could do because of scammers and/or simply just clumsy scripters who don't know how to work it.  It's too risky, so the Lindens may have no other choice but to make it very scary to accept.  LoL  Well, it is scary.  I thought it was a scam when I first encountered that permission thing and so would most people...I guess they did that deliberately.  Oh well.  What could they do otherwise to prevent scammers?   Scammers and clumsy scripters put this in a forever box of not being able to work without a fright message.  So, I was wrong there about the Lindens.  It's sad kind of, the power scammers have over this, as the extra sales lost is a tremendous loss to everyone, imo.  

Edited by FairreLilette
  • Haha 1
Link to post
Share on other sites

Let's start with the scenario that Franco has a demo of Stalin's product; Franco wants Stalin's product and Stalin wants Franco's money. Unfortunately they're both mutually untrustworthy (but in case it helps, they both trust Casper the Friendly Ghost 👻 ).

The problem is that if Franco gives permission to an object Stalin scripted, it will try to steal all his money. Is there some way Stalin can prove to Franco that this time he'll just take the agreed amount? For example, can Stalin show Franco the script or somehow provide ironclad proof that it's the same as a known "safe" script?

Nope, there's no way for Franco to see inside a no-mod script, and Stalin can't trust Franco with a modifiable script, and there's no way to compare scripts without seeing inside. (Theoretically there could be a script comparator, but that's not a real thing now.)

Instead, what if Franco had a script of his own that he can trust it? Could he use that to order and pay for the product from Stalin? Well, maybe, if only Stalin had a way to confirm that he really got paid by Franco's script. Unfortunately, there's no way for an object to pay another object, so that can't be part of confirming payment; Stalin's paid-delivery process would need to include scraping his L$ transaction record to confirm the payment really came through. That's not completely impossible, but it's a reliability nightmare, with so many potential points of failure (even assuming nobody is trying to play tricks on poor Stalin).

So failing all that, is there some way Casper (remember Casper? 👻) can help? Imagine Casper has written and released one and only one script, ever, and every competent scripter agrees that this script is a valid and trustworthy payment-conveyor. He 👻 releases it copy+transfer, no-mod, and we enlist the good offices of the Lab to concur that this one script is what it says on the tin and that Casper's account is now permanently nerfed such that it can never login again and release another script. That one and only one script can be confirmed to be created by Casper, and since there's only one such script, we know it can be trusted because everybody said it was trustworthy.

In order for Franco to trust to pay it, though, it must live in an object with one and only one script in its one prim -- so it can't be in the demo object itself, it has to be a standalone thing owned by Franco with debit permission from Franco. (Somehow it learns about the demo and who to pay what amount to order the non-demo product. Could be a communication API or a drop-into-inventory action or some other magic that an unsophisticated Franco can perform.)

And here's the challenge: What exactly must such a trusted script actually do such that every competent scripter agrees it's doing the right thing?

To convey the order, it must tell Stalin's fulfillment processor that Franco has paid the amount actually paid (avoiding the L$ transaction-scraping failure pit), and identify the product  and recipient corresponding to that order. Stalin's fulfillment processor is responsible for confirming that the amount paid indeed entitles Franco to the ordered product, and if so, sends it. And everybody's happy.

There's probably some obvious flaw in this (besides the Linden Confederate it magicks of thin air) but I'm apparently too sleepy to see it. Sorry for so many words to describe a simple, probably fatally flawed idea.

Edited by Qie Niangao
  • Like 3
Link to post
Share on other sites
2 hours ago, Qie Niangao said:

There's probably some obvious flaw in this

Flaw?  Yes, it's flawed because of greed and scammers.  You cannot pay yourself of any object you own so you need a kind of relay system to pay another person from an object you own.  And, LLTransferLindenDollars is it and it has a scary message because people need to learn about this kind of transfer money system and usually seek help before they trust it because it looks at first glance like it's a scam.  So, it's only useful to club owners and that's about it.

I'm pretty sad about it Qie because the difference in lost revenue could be a car for someone or even more because of scammers.  Cars are important; paying electric bills is important.  The flaw is greed.   Sorry, just found it all kind of sucky and it's not about revenue for me.  I'm just a little bit of hobby money kind of builder; I never cash out Lindens...I spend them in SL.  But, for others, they should be able to get what's due them for their art.

But, I also heard we have to accept life on life's terms.  We cannot change a lot of things.  

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 257 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...