How do I check if vendor info has changed after clicking PAY?

I have a vending machine where you can browse thru items and purchase them. If you click PAY, then someone changes the item on display, the new item will be the one given to the payer, not the item on display when the user clicked PAY. I noticed the pay event is only triggered when you've decided how much to pay, not when you actually click PAY on the object. Is there a way to trap that first click? That way I can give them the object that was being displayed the instant they clicked on it. Hope this makes sense.

One solution is to block other customers from changing the vendor for several seconds after the vendor is touched (along with an IM asking the second customer to wait until the first customer is done). The idea is that a customer cycles through the vendor... if the customer then clicks to pay, they have a 10-sec (or longer) cushion where nobody else can interfere.

A second solution is to use a different price for each item, even if only L$1 different. If you would normally sell 5 outfits for L$100 each... range the prices from L$90 - L$95 - L$100 - L$105 - L$110. Then, compare the amount paid to the price of the displayed product. The difference should average out over time.

But to answer your question, there is no LSL event to 'catch' a right-click/pay.

Ah, if there is no event to catch the right-click/pay, then I can't trigger a 10-sec cushion. The problem lies between the time they right-click, till the time when they select the L$ amount. Only the latter event can be captured.

Setting everything as different prices works. I'm able to detect the change that way. The vending machine is customisable tho so I'd have to make sure everyone who owns it enforces this rule for all their products.

You have a key flag signalling that the vendor is not in use (NULL_KEY).

When somebody now starts browsing your vendor you set that flag to the user's key.

And whenever someone clicks your vendor (prev/next/product info/...) you simply check if the key flag is NULL_KEY and if not, you check if it is identical to the clicker's key. If yes, set a timer event to say, 30 or 60 seconds. (llSetTimerEvent(45.0). If no, dispatch an IM telling the user that the vendor is in use by someone else.

Also do the check on payment to make sure the proper person paid you.

Once the timer event happens, reset your key flag to NULL_KEY and you are ready for the next customer.


Details and actual script code are left for the student to write and refine.

Some useful tips in there, thanx Squirrel. However, there is also the case where a user simply pays the vendor without creating any other events beforehand (such as touch). The vending machine displays all the information about the product so 97% of purchases are made by people just right-clicking then paying.

which would be no problem as the key flag in those cases would be NULL_KEY and thus the vendor free for use.

Only when it is NOT NULL_KEY it would be in use and thus other people need to be kept from using / paying it.

You still could have the situation where a vendor is sitting idle, Resident A walks up and says, "Hey I like that", right-click/Pay, and before they can hit the payment button, Resident B cycles the vendor.

Untested, and just thinking off the top of my head: set the left-click action on the root prim to Buy Contents. Put the full inventory in a child prim. When clicking the selector, actually change the root prim contents, using llRemoveInventory() and llGiveInventory().

so I right-click and pay...

and while I'm in that dialog someone else cycles the vendor and locks it to them...

no problem.

vendor locked, payment processed => key flag not NULL_KEY => refund => Sorry, vendor in use.

I have been trying to find an answer to this same problem for some time.
I have a rotating ad vendor. The ad changes every 30 seconds or so...
The vendor contains 30 items all the same price.
If a customer right clicks to buy when say the display time on the current ad is at 28 seconds, by the time they get the payment in, the ad has changed.
If you come up with a solution... please post here for all to see...

From the info I have I can see 2 options so far:

Lock the vendor for some time when its being changed or manipulated. People who have paid during this time will get refunded. This will fix up problems with someone who has the pay dialog open while the item changes. However, anyone attempting to purchase during the lock period will not be able to do so. I'm not keen on this one because my vendor changes according to time and this would mean everytime it changes product, no one can purchase for 10 seconds or so after its changed. This also won't catch everyone who has the pay dialog open. If someone has it open for longer than the lock period, it won't work.

Give all the products a unique price. In this case the price also acts as a unique ID so you can tell exactly which product the payer intended to buy by the payment amount (I use set payment buttons). This can be a bit of extra maintenance and could be painful if you have a lot of products. The problem is other people are using this vendor. I'd have to get all of them to change their price lists.

If anyone can add to this, feel free!

Other options:

Give the customer some reason to touch some part of the vendor before it goes into a "purchase" state where it can be paid. i.e., the default "attract" state doesn't have a money event, the "purchase" state does; the "purchase" state lasts until a proper payment is received, or a timer elapses. While in the "attract" state, the vendor cycles products automatically and/or manually. While in the "purchase" state, the vendor is locked onto one product (or onto that customer), but not for long.

When paid, give the customer a dialog of products available at that price and have him select which one he wanted, including a "never mind" option which refunds his money.

here's what I've decided to do. Its not the perfect solution but its the one that least inconveniences the user. I didn't want a solution where they get locked out, refunded or are asked to select which product they wanted.

I'm going to use the unique prices to differentiate between the products. I am storing the previous item details so if the new item has the same price, I will automatically add (or subtract) L$1 to its price. This way I can check if the buyer wanted to buy the new product or the previous one. Only 2 consecutive products need to have differing prices, so if my vendor cycles thru 4 products costing L$300, 2 of them will actually have a price of L$301. I will just have to make sure the vendor owners are aware of this. Hopefully that L$1 difference won't get anyone off-side. Of course, this won't catch people that have the pay dialog box open for the cycling of 3 products, but if they are that slow, they deserve to be ripped off

heavens forbid LL lags the sim... remind me not to shop there

Sorry Macro, but you came up with the wrong answer. There are more then enough vendors available that are scripted right and work correctly in all instances. They are avalable for the equivalent of $2 to $4. When it comes to money you either have to get yours working right or go and buy one. Half-baked is not the way to do it.

You have all the time in the world to learn scripting, and it does take time, no way around it. It doesn't even matter if you are familiar with other coding or scripting languages. Learn, play, enjoy. Post questions here and maybe help answer questions. Learn to script different things and work your way up to scripting a fully functional and accurate vendor.

My apologies Lord Barnett. It was just an idea. I think I'm going to go with what someone mentioned before, getting the buyer to "touch" something first. That way I can record the product on display at the time the touch event occured. If they pay without touching, they will just get refunded. I have to sacrifice a bit of usability to do this but at least it'll make it work thru all instances.

my suggestion is to check out how other people have handled the same problem... I believe KDC's vendors use a similar touch system...

my though would be a broses state and a lcoked out buy state, with a timeout, you can shorcut the timeout in the money event, so that the only time the vendor is locked is the brief time between touching and paying, or a slightly longer timeout if they change their mind in between touching the prim and actually buying... most users won't notice the lockout delay just the extra touch.

I am sorry too if you mistook my comments as an attack or putdown, they were not. They were addressing the difference between scripting for fun or learning as opposed to putting a finished product up in your shop or out in the market. Once you cross the line over to others using your product then it must work correctly all of the time (although it is understandable if LL breaks it, which they do every now and then). Once your product is in the market, your name and reputation are on the line. You never, ever want to give people a reason to start bad mouthing your product or service. Competition is bad enough as it is.

Murphie's Law applies double to scripting.

There isn't much I can't script now, but it wasn't always that way. I recently donated a 3d Radar to the library. I had been wondering off and on how to do that for over a year. Finally I sat down, attacked the problem and it all came together effortlessly.

As I mentioned; hang in there, have fun, enjoy yourself, learn and play. It will all eventually come to you. Who knows what all you will be scripting this time next year.

Lady Jesse Barnett

simplest would be as suggested

register the uuid of the person browsing the vendor as a global
add an user uuid check to see if it is used by the registerd user or not
using a timer you can free up the vendor with emptying the key or simply reset the script

could be problematic if a user decided to buy the item displayed before browsing

not if it`s only done on the back and forward buttons with a linked message and you allways get the user key from the money() event to give them the item on display as that isn`t reset

What about making a blue menu pop up on pay which asks the user whether she/he really wants to buy product xy? You could present the name of the product in the dialog adding an OK- and a CANCEL-button to the menu.

You would have to store the uuid of the user together with the last clicked product (maybe in a list, so more than one user can operate the vendor). If a user clicks «buy» you simply present her/him the last shown product, otherwise you read out the product from the list.

If the user clicks OK, you deliver the product - if she/he clicks CANCEL, they'll get a refund.

This surely is a little obstacle as well for the user, but as much as I hate «do-you-really-want-to»-buttons, I'd feel quite ok about this question...

Just my 2c

the scenario I'm envisioning is user a walks into the shop, the decide to buy what is selected (without cycling the vendor), hit pay, and before they hit pay user b cycles the vendor... if the pay amount is the same, user a ends up with the newly displayed item... what we're trying to avoid. you could refund user a since their key is not captured, but that means any user that wants to buy has to first cycle the display which could be annoying when what you want to buy is already being shown.

I do like the unique price system (all items have their own unique price) but it's not very feasible if you are selling items that are variations on a theme (as many no-mod items are)

About the only other suggestion I can think of is to scan for people, and require someone to be within a certain range and arc in front of the vendor, and lock the controls to them for a short time, but that is not without problems, either. Lots of places won't allow you to use sensors in vendors due to the lag they cause.

It's like making an incredibly complex clockwork machine to crack a nut. No matter what, you still are going to get shell pieces in with the meat, and the machine's complexity introduces other problems as well.

There are an awful lot of vendors out there which either use a simple solution or just don't bother worrying about the issue, because it actually is a fairly rare edge case, easily enough resolved a number of ways outside of scripting. Luskwood's vendors are probably some of the more bullet-proof vendors out there, and they solve that problem mostly by using an "in use" lock. Rarely does someone buy the currently displayed product; rarer still, do they buy it when someone else is using the vendor, and rarest of all, do they click the payment button on the pay dialog the instant someone else steps up and uses the vendor. Yes, it does happen, however the ratio of borked transactions to successful transactions is very, very low, probably on the order of a fraction of a percent, at most.

hmm true, guess the price scheme is the only way to go about it and hope some sort of change will be added at a later time

Haven't played with it yet but I was looking some last night. As previously mentioned, get the key of the person who either left or right clicks the vendor 1st. Then if anyone left clicks it they will recieve a message stating that the vendor is in use. If they right click it to pay then have an if test in the script so that if it isn't the same key, then it uses llSetPayPrice(PAY_HIDE.

Once the 1st person pays or the timer event expires then the key is set back to "".

But then again as noted, I haven't actually tried it yet. Hope it helps. I'll be playing around with it some tonight or tomorrow.