One prim vendor for multiple objects?

Someone called it a 'click target', I suppose similar to sit targets. Where you desginate that if someone clicks this area on a prim, this script will operate.

I've been scouring libraries and the lslwiki, but can't find what I'm looking for. Any help?

It's a simple touch activated event. Take a look at . If you are interested in writing a script to respond to touches on specific areas of a prim, study the various llDetectedTouch functions, starting with .

http://wiki.secondlife.com/wiki/LlDetectedTouchUV

see "functions" at the bottom of that page for other ones like llDetectedTouchFace(), ect

Thank you for your help!

I used those to build a 1 prim vendor...
https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1291578

Not only is it a beta version, but a bigger problem is something you tout as a feature which instead is a problem:
This is considered very bad practice, please see the money event in the LSL wiki which warns about relying on the preconfigured pay prices.http://wiki.secondlife.com/wiki/Money

its only bad if you do not check whats actually being paid

there was (or maybe still is) an exploit where people could rip off scripts that did not check the incoming amount, assuming that pay price was 100% foolproof

the only reason to require payouts is an incorrect pay price. if a pay price is set, there are only three possible ways the wrong price can be payed in...

1) script logic error (directly referencing the shown item and not accounting for multiple users, or user initiated change)

2) general SL errors (LL blew something up)

3) the user has a customized client and is using it to game the vendor.

number one is under control of the scripter. and could still occur under change back systems (if buyer tries to game this they deserve what they get). number two is uncontrollable, and can strike any system. number three is a matter of buyers trying to game the system and they deserve to lose it.

you can still check that the correct amount is payed in without giving debit permissions. optimally if an incorrect amount is received, then the owner of the vendor is notified. if it looks like an honest mistake the owner could choose to refund or provide the correct item. if it looks like it's being gamed (0L$) the owner could choose to report it to LL (not that I imagine it'd help) or simply ban the person from their property.

From Nalates description on xstreet, "This vendor uses exact PAY prices. ....." it is not completely clear, but the way it is worded it would appear that he or she is relying solely on the setting of the pay buttons.

Could you expand on this, Void? It's been worrying me since it was referred to in a previous discussion at /54/32/314827/1.html.

At the moment, when someone clicks the vendor to change the item shown, I change the current_item name, current_item_price and current_item _texture and then change the single pay price button. Then, in the money event, I check if the amount paid equals the current_item_price. This sounds as if it's wrong, but I'm not sure what the right way to do it would be.

I have no idea how to "account for multiple users," in the sense that I can see ways for things to go wrong if someone changes the display at just the wrong moment while I'm in the middle of buying something, particularly if that changes the current item to another item of the same price, but I can't think what to do about them.

In the light of the previous discussion, my business associate and I have changed our vendors so we don't give refunds -- we now tell the customer that they appear somehow to have paid the wrong amount for the displayed item and please to contact my associate to sort things out (the vendor IMs her to warn her to expect this). We haven't had any problems so far, but we didn't in the past either, come to that.

scenario:
uses choses pay from pie menu,
pay dialog comes up, but user doesn't immediately click an option
user then clicks next item button (or someone else does)
user then clicks pay dialog

script compares price
if the item prices matched: user gets wrong item
if the prices differ
- they get the displayed item regardles of difference if no checking is done
- they get their money back if checking is done and give money is used
- they get nothing and lose their cash if checked as in my above example.

a super simple method (that only really works well with few items) is to just make sure that everything has a different price, then when checking, reference the price paid versus the index of the same priced item.

another method would be to capture the users selection of the item before they get the pay price dialog, and keying it to them. that way even if the page changes, the item index won't.

there's other ways, like locking out other users for a limited time, or locking the displayed page, but I think capturing the exact selection, and tracking that to a user will probably be the most secure...

something like a list with avKey, timestamp, selected item, [selected item], avKey, timestamp, selected item, [selected item], etc.

I think that'd accomodate multiple simultaneous users AND allow for cleanup (timestamp could possible be removed in favor of checking the sim for the av.)

Thanks so much, Void. That makes a lot of sense.

np, it's the first most common logical error I can think of in vendor design, and certianly one I made... and it confused the hell outta me before I realized what had happened.

as they said in the movie "21", always account for variable change.

i'm selling a simple vendor script on xstreet that can sell up to four different items from within a single prim AS LONG AS ALL FOUR HAVE DIFFERENT PRICES. the customer makes his/her choice by paying the price of the item he/she wants.

if someone manages to pay an amount that matches none of the configured items, the money is refunded.

https://www.xstreetsl.com/modules.php?CategoryID=85&SearchCurrentCategory=on&name=Marketplace&MerchantID=18266&