Vending customized objects?

I have been stymied in several separate attempts to solve the following problem, and would value some advice - I'm obviously missing the "trick".

I want to be able to sell objects that are created from various vendor-prim-inventory pieces in a customized way at the time of purchase. Not only do I want to combine the pieces from the vendor's inventory, but I also want to make the pieces linked together and even modify them in various ways - change textures, hole sizes, etc. Of course, obviously, I can create a script that lives in the various pieces to let me make the requisite changes. This requires that the widget be rezzed nearby while it's being customized and putting itself together. The widget is owned by the ME during that time - i.e., the owner is the owner of the vendor that rezzed the pieces.

The problem comes when I'm done with putting together the customer's new widget, and I want to actually SELL it to that customer. I can mark the thing as FOR SALE, at the proper price, and the customer can simply BUY it. But that is very clunky, and it means I have to have prims for several customers at once to rez their widgets while they're being put together and customized. And, of course, there's no guarantee the customer will buy it - someone else might come along and buy it before they can! And the customer might just walk away, in which case I probably would just tell the newly created widget to destroy itself after a timeout period of some minutes...

What I want is a way to build the thing up and then give it directly to the customer's inventory (after they pay, of course). But there's no way for an object to give itself to an inventory, nor is there a way for an external entity to do so, right?

I thought of packaging the widget's pieces in a box, along with a script to do the actual construction at the time of the customer's choosing when he opens the box. The trouble with this is that many customers would simply open the box and there would be all of my hard-earned textures and other stuff - all as separate pieces. There is no way to force the customer to TOUCH the box, or whatever, to trigger the script that puts the bits together and then obliterates itself, is there?

I actually have several separate businesses that would benefit from a solution to this problem. I suspect there are more. Maybe I'm just missing the obvious solution?

What do people do to solve this problem?

Thanks very much in advance for your wisdom on this subject.

Well, an object can give something from its inventory to a customer. So it might work if you build the thing, put the finished result into your vendor object's inventory, and then give it to the customer.

You can't do anything to items in inventory, except delete them, rez them, or change some of their metadata (though not via script).

From what you are describing, it looks like what you want to do is beyond the current script engine's capabilities.

Yes of course! But I need to make the customized version on the FLY as the customer demands. I can't create 65,536 combinations of prims. Never mind the size of the inventory, it's the time it would take to manually do that! SL provides CRAP for mass manipulation of prims and inventories!

It SURE would be useful if you could change with a script ANYTHING you can change with the client - things like the sell price, the protections, etc. It would also be very useful if you could rez some objects, do stuff with them like my customizations, and then put them into your inventory or the inventory of an object - all without manual intervention. SL is extremely hands-on; it sucks at doing things en masse.

I had the idea of making a scriptable mechanism that runs as a client as far as SL is concerned, but is instead something like a Python script executive that allows you to do all of the things an SL client can do. You could then hand a set of work (as a Python script and some prims, textures, etc.) off to this thing and it would just robotically do the work for you. Obviously it would have to be logged on as an SL user...

Unfortunately, I'm afraid this is true! Maybe I will go off and fix that by making a fake-avatar based solution that runs as an SL client. But it is a kludge at best to do it this way.

Instead of your vendor doing the work of putting the pieces together, you could give the customer a "maker" prim and for example ask them to wear it as a HUD. Then everything that gets rezzed from that point on gets done by the customer's HUD and is therefore also owned by that customer (so no need to transfer once built). You would have to come up with a way of communicating the customer requirements to the HUD. You could for example transfer all the type/shape/size/position/rotation and texture uuids/colours for each prim and rebuild and link them (you would still be shown as Creator so no worries there). If you make use of a couple of scripts in your product then you could include all of them in the "maker" HUD which all get included in rezzed prims and then purge the scripts you dont need on a prim-by-prim basis - each script could test to see if it's in a linked set and deactivate itself until it gets linked, and if its not needed just purge it before linking.

Or you could give the customer a "maker" prim which includes all the possible pieces, and only the pieces required get rezzed and linked together. Though in this case you'd have to put some protection in just in case the customer is able to drag all the pieces out of the prim's inventory - various ways you could do this so that making use of those pieces becomes a pain in the neck. Eg you could link in a large ugly prim which gets delinked by your script when pieced together, or obfuscate the look of the prims slightly and undo that while being linked.

Or the customer could pick the pieces from your vendor and they'd be given to the customer in a single folder. Then the customer rezzes all the pieces to the ground and they automatically coalesce into a single object.

Any subtle customization in any of the above examples could be communicated direct from the vendor, or by using token prims given by the vendor so that their presence symbolize a option picked by the customer, or communicate it via a webserver or email if you expect your customer to do all of this away from your vendor.

I know this is an old thread, but am wondering if anyone has found a viable option for this.

My use would be to have a customer cycle thru my poetry with one set of controls, then cycle thru backgrounds with a separate set of controls. And possibly toggle thru different prim desitnations (picture, card, book, etc) with a third set of controls.

The customer would see the result of his/her choices on screen and when pleased, would click buy and have the resulting item built.

It's either that or house every poem I have already "prebuilt" upon every texture I am offering. 50 poems and 25 backgrounds would take 1250 items in inventory instead of... 75....

I's a wonderful idea I wish I had it first. I believe it's feasible. Maybe I'll give it a go
It's doable at least partially for instance select a hat, a pant, a shirt and shoes. Chosing makeup for a skin is impossible as of now without human (or at least bot) intervention.

Anyway the day LL give us the url textures or whatever they call it, the possibilities will expand.

Lacie it's certainly possible to come close of what you need. make one prim with backgrounds, one with texts (this one transparent). put the transparent in front of course then you can cycle textures on both.

it's doable....

method 1
rez a sample object, use communication between the vendor and the item to set various attributes (the attributes should be in the script, it's not very secure to pass things like texture uuid's between them), rezzed item is set to buy, poof, user gets custom item, the customize scripts can be set to self destruct if owner != creator to clean up clutter

method 2
user pays object, recieves uncostomized object, object contains customize script (which contains all options, and auto reverts on rez), various dialogs later, customer hits save, extra scripts self destruct

option 1 is safer because the sample object can check for valid communications and self destruct it's scripts immediately if set to buy original... this also allows the object to be copiable, while it's a risk with the second version (but infinitely re customizable if not self destructed)

Anthony Hocken and Void Singer both present practical methods of solving the two problems.
In the first problem I'd be tempted to go for the "maker" object with a single uber-prim inside which is rezzed as many times as needed and then each prim is remoulded and textured etc as per the design.
For Lacie's problem I would go down the route of using a background texture and a poetry alpha texture together with storing each of the texture options as the UUID within a script, user drops the bought object next to the vendor which then tells it which options were chosen "Background 23 and poetry 12 please". Then the script in the object changes the texture to the UUID from it's memory and deletes the script from the object. Job done! Adding more poetry or backgrounds is just a case of modifying the script in each of the different object types and if thats too much work then transmit the UUID of the texture from the vendor system instead of an option number, then your UUID values are stored in only one script/notecard.

Both the 'maker' objects above could declare themselves unusable should they be rezzed outwith the shop from which they were bought until they are returned to the store for their settings.

Yes! The technology would have other applications. As you mention allowing someone to customize an clothing ensemble and see how it looked together before purchasing is certainly on of them.

Once the code for selecting parts is written, various vendors could be built that would accomodate the different items being sold.

For my purposes, a single display window with the alpha text rezzed over the top of a background would be suffcient.

For clothing, perhaps a rough picture of an avatar and as an item was selected it, it would rez in the appropriate part. Controls could be different as well. In addition to the standard left/right arrows... the clothing vendor for example could allow the customer to click on any bpdy part to choose/change first and then change the item for that part with the left/right clicks.

Of course the delivery is different in both cases. My needs require assembly of of an item, the clothing requires packaging of multiple items.

Though such vendors may exist in SL, I have done a bit of searching and not found any. It seems like there could be a market for vendors with these capabilities.

I realize we are constrained by what SL will permit us to do. (sigh)

But, in my mind, in an ideal world, the vendor would do all the work. The customer would spin the dial, click the button and when he/she got the combination desired would click buy, the item would then be built and delivered without any further action required of the customer.

But if SL limitations require customer interaction, then *after* they had chosen and paid for the item....rezzing a "maker object " at that point would be acceptable.

All this would be made much easier if there was a way for an object to give itself to an avatar. Maybe there is a request for this in the JIRA. If this was possible the product could be built on-the-fly behind the scenes (outside the vendor, but out of view, not necessarily in the same sim) and then ordered to give itself to an avatar. The icing on the cake would be if the llGiveInventoryList function could be amended to include the object itself, so the customer receives the custom object along with instructions notecard etc all in a single folder. I doubt the possibility of abuse is much different than the ability for a prim to give an item from it's inventory to an avatar which is currently possible.

Been several months since i last commented in this thread so can't remember if i mentioned this but what you could also do is self-assemble the customized product in front of the vendor and then just allow the customer to buy the object itself. And if cancelled or untouched for a few minutes just self destruct (umm, the object not the customer).

There's no perfect solution but plenty work-arounds that aren't quite as polished but should work fine.

Re the poetry vendor. Personally I would be tempted to have one object per poem and just allow the customer to customize the background once purchased. It would be a bigger incentive to buy because it feels like you're getting more for your money, and less indecisiveness/decisions before commiting to purchase. Not that the vendor idea itself isn't neat.

I know this is a silly idea, but can an item in inventory like a texture be given by uuid? and if so, has anyone tried grabbing a rezzed objects id and attempted to give that?

I once had a though to have a customizer load variables into an objects description, with a preset name, rez it, the user clicks buy, then drops it into the object they want to customize, and that spits out the options they want after reading the description variables

another thought is to preload a script w/ variables, rez an object to buy, give the script to the object which sets it up, and then the user buys it

But one would use llGiveInventory, right? and the rezzed object won't be in Inventory. On a lark, I tried it, and not surprisingly it threw "Unable to give inventory: No item named '[the keystring here]'". That would be exceedingly cool, but I don't know of a way to preserve state when copying a script. As far as I can tell, whether llRemoteLoadScriptPin starts the script running, or if another script turns on the copied script with llSetScriptState(TRUE), it behaves as if reset at that point. (My tests of this were pretty cursory, so maybe there's a way and I just didn't do it right.)

FWIW, my approach to this has been to temp-rez a "For Sale Original" object and "accessory" components, yammer at them with obscure-channel llWhispers that get them to link together and that then instruct them to texture themselves, etc., with llSetLink- calls. If bought before the assembly vanishes, CHANGED_OWNER triggers an llSetPrimitiveParams([PRIM_TEMP_ON_REZ, FALSE]). So far I haven't gotten caught by the temp object getting garbage-collected during that brief interval of being temp-rezzed after purchase, but it will happen someday, I'm sure. And it's pretty ugly, requiring more than desirable instructions to would-be customers.

please if anyone figures this all out (it's greek to me) i'd love to have this ability... i want a vendor that shows possible combinations of items and then sells it all at once....i'll hire *anyone* who can do this for me

I didn't realize that llGiveInventory would reset the script in the new object, but it makes sense since this is the behavior when taking a script from inventory to an object

I suppose the best workaround method is to have all your info in the script that's in the "display model", and chat commands to it like "option one b" or some such... make the script only run if (owner = creator) and remove itself if it doesn't... could even have the script rez the options from a simple inventory prim, and customize them accordingly using setLink calls...

is there a way to set 'buy original' on the fly? or even the buy price?