Jump to content

Upcoming LSL feature: llTransferLindenDollars and transction_result


Kelly Linden
 Share

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

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

Recommended Posts

  • Lindens


GummieBear wrote:

Just a quick Q about this, great work By the way, as this results in a transaction id, will there eventually be a way via script or HTTP request to 'pull' and view a given transaction record? if this already exists please let me know as well.

 

Peace.

There are no plans at this time that I am aware of for this kind of feature.

Link to comment
Share on other sites

  • Lindens


MB Robonaught wrote:

Hi that'll be handy when available. I was wondering are there any plans on having a way to save multiple replies from the function in a text form instead of just memory? In memory that can really lag things bad if one is getting dozens of hits and even hit the cap for list storage

Not that I am aware of at this time.

Link to comment
Share on other sites

MB Robonaught wrote:

Hi that'll be handy when available. I was wondering are there any plans on having a way to save multiple replies from the function in a text form instead of just memory? In memory that can really lag things bad if one is getting dozens of hits and even hit the cap for list storage


One solution is to ship it to out-world storage, such as email via llEmail or a web server with http_request, that way at least you could have a reference you could look at later for comparison if an issue arises.
Link to comment
Share on other sites

data will contain a CSV of destination id and amount transferred on success and an error tag on failure.

 

I would interpret this to mean that on success there would just be 2 items in the cvs list and on failure there would be a third, currently on failure you just get the error tag.  I think that both the destination id and a amount transfered should also be included on failure.  This will allow the script to more easily retry a failed payment.

 

example:

    transaction_result(key transaction_id, integer success, string data)    {                list data = llParseString2List(data,[","],[]);        string error = llList2String(data,2);                if(error != "")            llTransferLindenDollars(llList2Key(data,0),llList2Integer(data,1));                  }  

 

Link to comment
Share on other sites

Great idea, completely agree with that, but the status would have to be returned all the time with data because if they in future make the string data return more stuff, it would break back-compatibility.

Would be just enough to have the success return 1,2,3,4... and have those values stand for certain error, just like PRIM_POSITION or so.. But it would be great to have the function return the agent and amount all the time.

Link to comment
Share on other sites

Rather than adding a new feature why not do something really radical and needed, curtail adding new material for the rest of this year and actually take the time to fix the problems that have been caused by piling half tested or maybe untested new features onto an already overburdened system.  I realize this is a bit to ask of LL, but we do pay for adequate service and they are giving anything but adequate service at this point and it is high time they fixed this mess before it carshes around them like a house of cards.

Link to comment
Share on other sites

Frankly, most makers and significant users of vendors that I've talked to *DO* consider this a major bug fix.  The previous calls are being left in place for the time being under the Linden Lab policy of not breaking content, but in the future will likely be marked deprecated, and eventually removed.  This is a much more important fix for most people, I believe, than any other bug in the system right now.  Vendors able to tell when a transaction fails, and why?  Oooh, I can see LL's support costs falling rapidly!  Go look at SVC-114 on the JIRA, where Intan has been sending people to post about inventory loss - I expect a number of those complaints would have never occurred, because the system would be able to tell the user *WHY* the transaction failed.

Link to comment
Share on other sites


Kelly Linden wrote:

  • data
    will contain a CSV of destination id and amount transferred on success and an error tag on failure. 

Is this a good idea, given that the Linden CSV parsing functions are broken?

See SVC-285 for details.

I saw in a previous comment that you believe this to be more general, but really a list is more general since it can contain any type without quoting or casting errors (eg, from converting between floats and strings).

Link to comment
Share on other sites

  • 2 weeks later...


Strife Onizuka wrote:

I've gone ahead and written documentation for the functions based on the RC release notes.

- I'm not happy with the table. Will revisit it later.

Wow...long time, no see.  Hope all is well and Happy Holidays!

Link to comment
Share on other sites

  • 3 weeks later...

>> The only script in an object which will get a transaction_result event is the script that called llTransferLindenDollars. This is similar to how the http_request event works.

Actually, that's not how http_request event works. The http_response is sent to the prim, not the script, so you can send http requests in one script and receive the responses in another - which I do in one of my huds to distribute processing.

Whether this is the same for llTransfer events I don't know, but you are welcome to try it out :-)

Link to comment
Share on other sites

  • Lindens


Strife Onizuka wrote:

I've gone ahead and written documentation for the functions based on the RC release notes.

- I'm not happy with the table. Will revisit it later.

Thanks strife.

Link to comment
Share on other sites

  • 4 weeks later...

I just wanted to say thanks for implementing this function. I think the ability to confirm a successful transaction before delivering a product is critical. We will be building this into the newest version of our affiliate vendors to replace the much more complicated system we currently have in place to confirm transactions.

Link to comment
Share on other sites

  • Lindens


Cold Spitteler wrote:

SERVICE_ERROR is returned in some situations where the transaction was succesfull.


This was determined to be an error in the lsl scripts and not a bug in llTransferLindenDollars. Specifically the scripter had added his own timeout which was shorter than the time a successful transaction could take and was not verifying the ID in the transaction_result message matched the one given by llTransferLindenDollars. This meant the script would associate the results with the wrong transactions.

 

  • Always verify the transaction_result id matches what you expect. If possible keep a list of IDs to handle the case of multiple transfers.
  • A transaction can take up to a minute and still succeed.
Link to comment
Share on other sites

  • Lindens


Lyle Maeterlinck wrote:

I just wanted to say thanks for implementing this function. I think the ability to confirm a successful transaction before delivering a product is critical. We will be building this into the newest version of our affiliate vendors to replace the much more complicated system we currently have in place to confirm transactions.

Glad you are finding it useful.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3551 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
 Share

×
×
  • Create New...