llbuy() function and event - a no brainer!!!

hi everyone, please take a look at this feature request!!

https://jira.secondlife.com/browse/VWR-3323

The creation of "llbuy()" event. This event would allow a script to receive instant transaction information when someone 'buys' an object, or it's contents. With this information, the script could then do so much with this information. It could contact an external database and record the data. It could IM the owner to notify them of a sale. It could store the info into a list, which could then be emailed to the owner at the end of each day, etc. The information could be similar to the transactions page on the SL website. The buyer, the object name, the time, the region, the price etc.

llbuy seems to be a no-brainer!

Thank you!

(you can get some info when someone 'pays' and object but not when they 'buy' an object or it's contents)

I guess I can see that an event might be useful but I'm not so sure about a function.

What would the function do?

Hmm maybe a function isn't necessary, but the main point is allowing a script to receive the buy information. It makes no sense that of all the information available to scripts, a standard 'buy' isn't available.

updated...

Everyone, please read and vote on this feature request.

If you sell things in SL, you are probably aware that the transactions portion of the website only keeps the last 30 days worth of transaction information available. This will give us a way to maintain proper records of purchases...

Cheers

llChangedOwner( )?

(Or actual equivelent that already exists)

Agree with Draco18s, the changed() event already fires when someone buys an object. The difficult part is detecting what happened, as it can be unreliable. The most annoying part being that changed() will fire even if you don't want it to, which makes some things (for example sit-scripts) more complicated if they're going to be sold in this way.

Really we just need a better documented example of changed() event and the "Buy" option on the wiki.

Ok woah. Maybe this event should only be for buy copy or buy contents. Then the script inside the vendor would retain the script.

Changed event doesn't tell you the cost of the purchase. Without the cost being available, changed event it pointless for what the llbuy event is intended to do. llbuy is specifically for tracking purchases or transactions. We need the same information that's available in transactions history, to be available in world within a script.

How can you NOT see this as useful? That is the question...

Another possibility could be lltransaction. This event could be triggered anytime a transaction occurs between you and someone else. You could then have a master controller object who's job would simply be to process all of your inworld transactions. You could have it ignore 0L transactions if you wanted. This information is already being sent to and recorded by LL for their transactions data that they display to you. lltransaction would simply push that same data to you in real-time inworld. What you do with it from there is up to you...

I think part of your problem in your argument is the terms and formats you are using.

Functions have llFunctionName() format. Events (which I think you are trying to propose), do not. They are instead named things like sensor() and on_rez() and touch_start().

LSL does have a money() event, which triggers whenever an object containing a script is paid. It's not exactly in the ballpark of what you are wanting, but it does give you the payer's key and the amount paid, but not anything about inventory items changing hands. The changed() event can handle that to some degree, as mentioned above.

I don't believe the money event is triggered when someone buys the contents of an object.

If the proposal was for an llBuy() function that then allowed the money() event to fire when an object is bought then it might be good. As I understand it adding whole new events can be difficult (currently).
Plus the money() event already has all the things you'd need from a bought() event, so there's not much point in duplicating it under a new name.

Hey, whatever works. We just need to have access to transaction info when someone 'buys' a copy of or contents of an object. I don't care how we get there, let's get there...

The problem with most "no-brainers" is that's usually more of a statement of how much thought has gone into them than of how much thought they require. I've burned myself too many times with the same phrase!

I don't feel burned at all - funny huh. I still think a buy event, or a transaction event is the way to go.

No brainer!