Pay vs Buy & Temp On Rez Boxes

heyas;

so i was thinking... (yes yes, there will be a question at the end).

setting up an object or a box to buy is the built-in basic way of configuring something to sell. the user right clicks, selects buy, gets a list of stuff being bought (if its a box anyway), and then buys or cancels the transaction.

setting up a vendor requires scripting, and using the pay options and money event and suchlike and so forth. i wont get into details here of course, but there is a way to exploit this setup. then there's the delays and possible hitches concerning the money event, the llgiveinventory event, and all that transactional nonsense.

so what would happen if, instead of doing all that pay/money/giveinventory programming, you had a vendor that just rezzed a hologram box (temp on rez) that was the original box of the first scenario, where you just right click on it and buy? wouldnt that bypass a lot of the headaches and potential problems of the vendor pay method? would it be worth it to possibly lose some functionality that vendors have?

ie: my vendor can be set to give group discounts, or have sales -- ie: change the price of the objects on the fly. some can use coupons or gift certificates. and, of course, some do split payments.

then there's technical questions, like CAN you buy items from a temporary box? they wont inherit the temp on rez property, will they? (that would be bad.) plus, of course, there's the question of, what happens if it de-rezzes between the time you click buy and the time you finalize the transaction?

hmmm.

okay, maybe im just nuts??

these are called holovendors, and they already exist.

Another way is to rez the 'real thing', no temp on rez.

Then when you want to change the selection, send a llDie() command via a listen before you rez a different box, to get rid of the first one.

But wait, you say - what if someone buys it and then the purchased box is killed by the vendor command?

Easy. Make sure that the box only accepts the command from the box's owner. Or you can get all fancy and script a 'my owner has changed, kill my ability to llDie()' into the box.

That sure beats any temp-on-rez approach, because the sim's temp object clean-up schedule is completely asynchronous with any script in the to-be-killed object. But I'm not sure how "atomic" the "buy" operation is; might there still be a rare race-condition here? During the interval between the purchaser clicking "buy" and the object getting a CHANGED_OWNER event, if it gets the llDie command event, what would happen? Can we be sure the purchase won't proceed even as the object is dying?

I don't know if the shop is there but I remember this hair shop in Reil that you could try on different wigs without them going to your inventory.
I have no clue how they did it but it was pretty cool.

I toyed with this idea, but got the eeby jeebies around the bun fights with people rezzing different stuff over each other.

That may be solvable though.

I'm sure there are about a dozen rare race conditions, a half dozen bugs, a swarm of timeouts and probably an asset server potty accident that are all possible, nay, even likely.

I suppose the question is: how much worse is it than just buying the object normally and having *that* fail?

My guess: not a lot different. I've known people to do this and never heard them have issue with it.

The reason it's not popular is this, I think: by the time you get into such scenarios you are already a successful merchant, and buying a bit more land for display prims isn't that big a deal any more.

You setup the Pay button with the script, you setup the Buy button when you set the item for sale. If you do not set the item for sale (which, in case of a scripted vendor, you wouldn't), the 'Buy' option doesn't appear. As far as a temp on rez vendor, the vendor is a seperate item from the temporarily rezzed item. The temp item is just for display, and one would set it to no copy of couse. Also, where's the headache in using a scripted vendor? I wrote my own vendor script so that I could personalize it to my liking, and found no headaches or potential problems. For me, it's worth it to use scripted vendors.


Yeah, but why would you when the box is going to disappear in a minute or two?

Do you mean 'Pay' ? The built-in vending capabilities trigger no events at all.

The *buy* method is the barest, simplest, least prone to SLuck-ups method of exchanging goods for L$ in SL. If a temp rez prim does something wibbly, it doesn't matter. If a network vendor poops its pants, you're in trouble. If a scripted vendor fails to deliver, you're in trouble.

I still get problems with buy box transactions, but adding LSL scripting into the chain is an extra level of potential tradewrong.

Just to clarify, no, I meant "Buy"; I was responding to Desmond's idea for controlling the disappearance of the to-be-bought box, "Make sure that the box only accepts the command from the box's owner. Or you can get all fancy and script a 'my owner has changed, kill my ability to llDie()' into the box."

At least according to , the CHANGED_OWNER event *is* raised whenever somebody buys an object (the original or a copy). (As I recall, I in fact use that in some boxes to get messages about sales.)

But in any case, Desmond is quite right to point out that my hand-wringing over a possible rare race condition is obsessing over the least of many possible slips betwixt purchase and the buyer's Inventory. I'll try to revert to obsessive hand-washing instead.