Customising vendor (i.e. a vendor that customises)

What's the basic principle involved in making a vendor that sells a customer-selected customised version of an object? The customer would chose a combination of colurs and perhaps other attributes, watching the effect on a display model, and then buy the combination they liked.

The brute force approach would be to hold a copy of the object in every possible combination in its inventory, but it wouldn't take many different options for this number to get pretty big. There's got to be a more elegant way of doing this.

TIA for any suggestions.

things like color could be be done post rez, include a script in the generic item, set it to buy copy, and feed it some options via the start parameter... is one way. you won't get a lot of options that way though...script to delete on finished run.

another option is to rez the object set to buy, and communicate actively with it, changing the options, and then let them buy (I'd rez some sort of no touch shield around the object to prevent premature buys), script to delete on command or owner change.

you could also go the give route, encode all options as a notecard, give the object and the notecard, and let them drop the notecard in (or rez the item and give it directly to the object to process, but that's almost as ugly as keeping separate copies of the object...

you could do a similar action with given scripts, play with description fields, etc.

I think the configure then buy route appeals to me the most - and the touch shield is the missing piece of the jisaw that makes it all come together rather nicely. Thank you.

A warning to anyone who tries this method themselves: the changed event with (change & CHANGED_OWNER == TRUE) is triggered in *both* the vendor *and* the purchased copy when a sale is made. This behaviour *is* documented in the wiki for CHANGED_OWNER, so it's a feature and not a bug (And it does have a JIRA out on it.)

The work-around is to store the owner's key on state_entry and then test for (change & CHANGED_OWNER && llGetOwner () != owner) in the changed event.

Just sayin'.

supposedly it's avoidable if you set the permissions while the object is rezzed... then again, supposedly it's fixed (or so says jira)... you should probably update the jira if it isn't actually fixed.

In the JIRA I saw (http://jira.secondlife.com/browse/VWR-15258) the resolution is "Expected Behaviour": it's a feature, not a bug I guess it could do with a bit more prominence in the wiki, though I'm not familiar enough with either wiki editing in general or with the LSL wiki ethos to feel comfortable about doing it mtself.

ah, I saw a different jira (linked from the CHANGED_OWNER page)
https://jira.secondlife.com/browse/VWR-12880

it's marked fixed, and Andrew commented the fix was supposed to be in server 1.26

the one you found was triaged last, so I'm not sure they'll do anything about it..